Appearance
Building Effective Agents
一句话结论
这篇文章真正想说明的，不是“怎么把 Agent 做复杂”，而是“什么时候其实根本不需要 Agent”。多数 LLM 应用都应该先走更低成本、更可控的路线：单次调用 -> 检索 / few-shot -> workflow -> agent。只有简单方案明显不够时，再升级复杂度。
文章主旨
文章发表于 2024 年 12 月 19 日，核心观点很鲜明：
- 复杂不是目标，效果才是目标
- 不要为了“看起来像 Agent”而做 Agent
- 先把单次调用、检索、少量流程编排做好
- 只有简单方案不够时，再升级到 workflow 或 agent
这也是它和很多“先上自治系统再说”的做法最大的不同。它强调的是工程可用性，而不是概念上的炫技。
Workflow 和 Agent 的区别
文章最重要的区分之一，是把 workflow 和 agent 明确分开：
- Workflow：路径由人预先定义，模型负责执行节点
- Agent：路径由模型根据环境反馈动态决定
可以简单理解为：
- “先分类，再翻译，再润色”是 workflow
- “先搜什么、用哪个工具、是否继续、何时结束”由模型自己决定，才更接近 agent
很多人口中的“多步调用 LLM”，其实只算 workflow，不一定算 agent。
什么时候该上 Agent
文章给出的升级顺序很实用：
- 单次 Prompt
- 单次 Prompt + 检索 / few-shot
- Workflow
- Agent
这个顺序背后是很典型的工程思维：先做最简单可行的方案，再逐步增加能力。
之所以不该一上来就做 Agent，是因为它的成本很明确：
- 更贵
- 更慢
- 更难调试
- 更容易累计错误
- 更难保证稳定性
所以关键不是“能不能做 Agent”，而是“这份复杂度值不值得”。
对框架的态度
文章并不反对框架，但反对被框架牵着走。
框架和 SDK 的价值在于：
- 帮你快速起步
- 帮你处理调用链、工具定义和编排细节
但它们也会带来明显问题：
- 增加抽象层
- 遮住底层 prompt 和 response
- 让调试更困难
- 诱导你加入本不需要的复杂性
更稳妥的做法是：
- 先直接理解 LLM API 能力
- 很多 workflow 本来就只需要少量代码
- 即使用了框架，也要清楚底层到底发生了什么
一句话概括：框架是加速器，不是理解替代品。
Augmented LLM：一切的起点
文章把最基本的构件叫做 augmented LLM，也就是“增强型 LLM”。它不是裸模型，而是一个已经接上外部能力的模型，例如：
- retrieval
- tools
- memory
这意味着，Agent 不是“另起一个新物种”，而是围绕增强型 LLM 继续做编排。
从工程视角看，一个 Agent 能不能真正工作，不只取决于模型本身，还取决于：
- 能不能访问环境
- 能不能正确调用工具
- 能不能保留和使用上下文
- 能不能根据外部反馈修正行为
其中一个非常关键的点是：给模型的接口必须简单、清晰、文档化。
五种常见 Workflow 模式
1. Prompt Chaining
定义
把任务拆成一串顺序步骤，前一步的输出作为后一步的输入，中间可以插入程序化检查。
适合场景
- 任务可以被清晰拆成固定子任务
- 希望把复杂任务拆小，提高稳定性
例子
- 先写大纲，再检查大纲，再生成正文
- 简历优化拆成提取经历、判断岗位、改写 bullet、统一语气、最终审校
优点
- 易控制
- 易调试
- 可插入中间校验
- 易定位具体哪一步出错
缺点
- 调用次数更多
- 延迟更高
- 链条设计成本更高
- 过于固定时泛化性会变差
它本质上就是最朴素、最稳的 agentic workflow。
2. Routing
定义
先对输入分类，再把不同类别送到不同的 prompt、模型或工具链路。
适合场景
- 任务类别差异明显
- 不同问题适合不同处理方式
例子
- 客服请求分流到普通问答、退款、技术支持
- 简单问题走便宜模型，复杂问题走强模型
核心价值
Routing 的重点是“分而治之”。如果试图用一个 prompt 覆盖所有场景，往往会出现某一类优化后，另一类反而退化的问题。
3. Parallelization
定义
把可独立的任务并行执行，或者对同一任务做多次采样后再聚合结果。
常见有两种形式：
- Sectioning：拆成多个独立子任务并行执行
- Voting：同一任务执行多次，最后投票或聚合
适合场景
- 子任务之间相互独立，需要提速
- 同一任务有不稳定性，需要提高置信度
例子
- 一个模型负责回答，另一个模型负责安全审查
- 多个 prompt 并行做漏洞审查或违规判断
这里很重要的一点是：不要让一次调用同时承担太多目标。
回答、审查、格式化、合规检查，往往拆开更稳。
4. Orchestrator-workers
定义
中央模型先拆任务，再把子任务分配给多个 worker，最后汇总结果。
和并行化的区别
- 并行化：子任务通常是提前定义好的
- orchestrator-workers：子任务是根据当前输入动态拆出来的
适合场景
- 事先无法完全知道要拆出哪些子任务
- 需要边理解问题边拆解执行
例子
- 复杂代码修改
- 多来源信息搜索与汇总
- 大文档分析
这个模式最难的地方，不是“怎么做某一步”，而是“怎么拆对任务”。
5. Evaluator-optimizer
定义
一个模型负责生成，另一个模型负责评估并给反馈，形成迭代循环。
适合场景
- 有相对清晰的评价标准
- 迭代能显著提升结果质量
例子
- 文案打磨
- 复杂搜索
- 代码修复
- PRD 或需求文档优化
它本质上是在自动化“先写 -> 再审 -> 提建议 -> 再修改”的过程。很多高质量结果，并不是一次生成出来的，而是多轮反馈打磨出来的。
真正的 Agent 是什么
前面的五种模式本质上都还是 workflow。到了这里，文章才开始讨论真正的 agent。
它对 Agent 的定义其实很朴素：Agent 通常只是一个能调用工具、并根据环境反馈持续决策的 LLM 循环。
一个可工作的 Agent，通常离不开四个动作：
- Planning
- Acting
- Observing
- Updating
关键不是“模型会不会想”，而是“模型能不能在行动中持续拿到真实反馈”。
为什么环境反馈很关键
文章反复强调，Agent 不能只靠脑补，必须不断从环境中获取 ground truth。常见来源包括：
- 工具调用结果
- 代码执行结果
- 测试结果
- 环境状态变化
如果没有这些反馈，模型就只能在自己生成的文字里自洽，很容易越走越偏。
所以 Agent 和普通聊天模型的关键差别，不在“多想一步”，而在于它是个闭环系统。
Agent 不等于什么
Agent 不等于：
- 多智能体
- 长期记忆
- 图结构推理
- 超复杂框架
这些能力可能有用，但都不是 Agent 成立的必要条件。Agent 的最低可行形态，往往只是“带工具循环的 LLM”。
什么场景更适合真正的 Agent
文章给出的判断标准很实用。以下条件越多，越适合上 Agent：
- 问题是开放式的
- 很难提前写死步骤数
- 无法硬编码固定路径
- 需要多轮操作
- 可以持续从环境中拿反馈
- 运行环境相对可信、可控
典型例子包括：
- 自动修复复杂代码问题
- 电脑操作
- 多来源复杂搜索
同时，文章也很克制地提醒：Agent 的自主性越高，错误叠加和成本放大也越明显，因此必须配合：
- 沙盒环境
- 明确停止条件
- guardrails
- 可观测与可回滚机制
一句话总结就是：能自主，但必须可控。
两个最有前景的应用方向
1. 客户支持
客服天然适合 Agent，因为它同时具备：
- 连续对话
- 外部信息访问
- 动作执行能力
- 相对明确的成功标准
它本质上是“既要 conversation，又要 action”的任务。
2. Coding Agents
软件开发也很适合 Agent，原因在于：
- 结果可以用测试验证
- 可以根据反馈继续迭代
- 问题空间相对结构化
- 输出质量更容易客观衡量
这也是为什么 coding agent 发展特别快。不是因为代码“更像智能”，而是因为它天然适合形成：
任务 -> 修改 -> 执行 -> 观察 -> 再修改
这个闭环。
工具设计本身也是 Prompt Engineering
这一部分很容易被忽略，但其实非常重要。
文章强调：工具设计不能只考虑“程序上能不能用”，还要考虑“模型是否容易正确使用”。
比如同样是“修改文件”，你可以让模型：
- 写 diff
- 重写整个文件
这两种方式在表达能力上可能差不多，但对模型的认知负担完全不同。像精确处理 chunk header、复杂 JSON 转义、严格计数行号，这些对人来说只是格式问题，对模型来说却可能显著增加出错概率。
更好的工具设计原则是：
- 给模型足够空间先思考，再输出
- 让输入输出格式尽量贴近自然文本
- 避免不必要的格式性负担
这部分可以浓缩成一句话：工具接口不是只给人看的，也要为模型的生成习惯设计。
三条核心原则
如果把全文压缩成三条原则，就是：
- 保持简单：不要一开始就堆复杂架构
- 保持透明：要能看见 Agent 在做什么、为什么这么做
- 认真设计 ACI：工具接口、文档、反馈和测试，都会直接影响系统表现
我的理解
如果把这篇文章再压缩成一句话，就是：
> 先把单次调用和 workflow 做扎实，再考虑 Agent；先把闭环和反馈做扎实，再追求自治。
它真正反对的，不是 Agent 本身，而是“为了显得高级而过度 Agent 化”。
评论区